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1,0 



.IMIRSm&IIfiM 



In contrast to corporate implications of "releases*** an S€S 
Release is a process by which SES Tools are made "available** 
for company internal use with support. In the presentation 
that follows* any reference to "release** should be interpreted 
in this manner. Definitions of other terms used throughout 
this document are tabulated in Appendix A. 

The objectives of the SES Release Process ares 

> To provide a timely availability of tools with a built in 
mechanism that allows for rapid repair of deficiencies. 

> To insure that uniform and dependable procedures are used 
to facilitate tool releases. 

> To tabulate the Tool Catalog file history in order to 
identify and recall any release version of these tools and 
to insure the integrity of the tools made available 
subject to the CONSOURCE Archive Policies. 



The intent of this Release Procedures Document Is to 
incorporate the purposes of the Release (stated above) into an 
organized program that insures consistency in the building and 
releasing of SES Tools. 

This document is divided into four main parts. The first part 
deals with the general release process as a whole. The second 
and third parts discuss the role of the Release Manager and 
the Tool Submitter* respectively. The last part addresses 
various aspects of the release: schedules* catalog management* 
and terminology. 
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2.0 __ItiE_££l£AS£-ERQ££SX£S-iB_££l!E&Al 



2.1 ££SI£_S£S£0MIMUII£$ 



A successful release of a group of tools is dependent upon a 
systematic and organized execution of the release process 
according to established guidelines. The release process 
guidelines have been defined to facilitate the tasks of the 
Release Manager in co-ordinating the release. A conscious 
effort should be made by all persons involved with the release 
to adhere to these guidelines. 

The fundamental responsibilities of the Release Manager are to 
co-ordinate the Scheduled Release process and manage the Tool 
Catalogs* In co-ordinating the release process* the Release 
Manager will attempt to synchronize within the pre— defined 
schedule the availability of materials* the execution of the 
verification build* and the final release of the new/changed 
tools involved* The section titled *»The Scheduled Release 
Timetable** provides a breakdown of these release process 
tasks* The management of the Tool Catalogs is discussed in 
the section named "Tool Catalog Management"* 

The main role of the Submitter Is to construct materials 
(i.e. tool PLs» build procsi and documents) for a tool's 
release according to the guidlines that this document attempts 
to establish and to submit these materials according to the 
defined timetable for the release* 



2 . 2 Ili£_fi£UiiS£.MHA^lL-AiJlLIflflL-SJifi!!III£E-IJ!I£&£A£f 



The mode of interaction between the Submitter and the Release 
Manager willy for the most part* consist of the exchange of 
memos* notes* listings* and documentation* Memos and notes 
will usually be sent to indicate either the availability of 
tool materials for the Release Manager or the status of 
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certain release process tasks being performed by the Release 
Manager. All such memos and notes should be clear* concise* 
and complete to eliminate any need for additional 
communication on the matter at hand* 



2.3 R£L£A££_II£££ 



Releases are designated by number and are usually scheduled to 
occur at six months intervals. {For more specific dates refer 
to the SES PERT*) The interval within which the release 
activities are performed is referred to as the Release Period 
and designates that segment of time in which specific SES 
projects are scheduled for completion and in which the 
official release process of the developed tools takes place* 
This also provides a definite reference point by which the 
availability of those tools may be expected* 

Within any given six month duration* there are only three 
types of releases that are conducted by the Release Managers 

Scheduled Release 

P re-Re 1 ease 

Critical PSR Release 

A Scheduled Release is that type of release which is performed 
during a designated Release Period* Since any number of tools 
are slated for release at this time* the release process 
follows a definite timetable covering approximately one 
man-month* The term "scheduled** has two implications here* 
that the point in time of a release has been pre-determined* 
and that the activities leading to this point have also been 
specifically laid out on a timetable. The intention of the 
scheduling is to facilitate the execution of each step in the 
release process for each tool submitted. Any tool that is 
scheduled for release must be in the pre-release at least ten 
days prior to Release Day (l.e* Day 10 or the Pre— Release 
Cut-Off Day) . 

A £ r. fir &g lease is designed to accommodate those situations in 
which a tool is made available in the interim between release 
intervals* The main reason for this type of release is to 
allow projects to release code with new features or minor bug 
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fixes on a more timely fashion* Pre-release information will 
be made available to SES Users who have expressed concern over 
the availability of specific tools* The general SES User 
Community will receive the information on these tools only 
when requested from the Release Manager* the Too! Submitter* 
or the Project Leader* Pre-Release Tools are not extensively 
tested* If problems are found* they should be reported 
directly to the Project Leader* 

A £Lili£&J._£££..££l££££ occurs when a critical bug is found in 
a current release and a temporary fix file is accepted from 
the Tool Submitter which is placed in the SES Catalog* The 
Submitter must eventually follow through the Scheduled Release 
process in order to make the fix official* 

The basic differences among the three release types is 
primarily a factor of when the tool is to be made available 
and for what reason* However* there are a few other 
components that further distinguish each type* The following 
table illustrates these differences* 



BASIC DIFFERENCES IN THE 
RELEASE TYPES 

SCH£QULE n ..EEL££££ £R£=E£i£M£ £MII£AL-££RJ£EL£AS£ 

Tool made available Tool made available Toot fix made available 

&£l££ the formal &£l£££ the formal immediately 
Release Period Release Period 

Tool is built by the Tool is built by the Tool is built by the 

Release Manager Tool Submitter or Tool Submitter 

Release Manager 

TAB blurb required TAB blurb required TAB blurb required 
and User Handbook 
corrections expected 

Access is default via Access is through a Access is default via 

SES procedure calls procedure call from SES procedure calls 

the SSS PROCLIB file (SES proc altered) 
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2.4 ££1£AS£_IA5K_AE£AS 

The activities in the execution of the release of any tool are 

shared between the Release Manager and the Tool Submitter* In 

the release process* there are four identifiable areas of 
acti vi ty i 

> The acquisition of Tool documentation 

> The build and verification of these tools 

> Distribution of released tools 

> Support for released tools 

2.4.1 DOCUMENTATION REQUIREMENTS 

In the initiation of a release* the first and foremost 
requirement is the submission of documentation that properly 
describes the new tools and/or changes to existing tools* 
Common to all three release types is a document offering a 
summary or "blurb" of the Tool's condition or situation. Each 
synopsis will simply consist of TXTCODE source containing a 
title line and a paragraph that describes the tool's function 
and/or its effected changes. The collection of all of these 
individual synopses under the title line 

TOOL AVAILABILITY BULLETIN 
and arranged by Tool name in alphabetical order will then 
compose the general construction of the Tool Availability 
Bui I et in { or TAB ). 

AM such "blurbs" should be sent to the Release Manager before 
the Pre-Release Cut-Off Day as the TAB will be made available 
on-line and also sent out to the general SES Communityat that 
time* 

In the parti caul ar case of a Scheduled Release* material for 
the SES User's Handbook should be received before other build 
related materials are made available* Usually* this 
documentation is included on a deck in the Tool's (main) PL. 
Other documents which may also be part of that PL and that can 
be submitted at this time ares the Tool's External Reference 
Specification (ERS) and the Tool Design Document —if 
avai I abl e. 
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The selection and the printing of listings is primarily the 
responsibility of the Submitter. Under normal conditions* any 
necessary listing for a tool should be generated during the 
execution of the build procedure or given to the Release 
Manager before the occurrence of the tool's release. 

The following is a list of required documents — some of which 
may be generated by the Submitter separate from the build 
procedures that are expected during the course of the 
scheduled release process? 



P_flc.uffle.aJt &&d&-Aa&Ll&hl& fax. 

External Reference hstQLS the Tool is released T00LD0C 
Specification 
(ERS) 

SES User Handbook i.£lfl£l the build process for — — 
corrections the Tool is started 
or addi tions 

Design Document hS.lQ.LS. the Tool is released T00LD0C 
( i f appl icab I e) 

Compiled Tool Source duiJLDa the build process Racks 
with cross-reference 
tables and expanded 
common decks 

Load Map lUlLillfl the build process Racks 



All such documentation received from the Submitter will be 
kept in a listing binder for common access by the general SES 
Community. Each tool will be kept in a separate binder and 
placed in an area designated as the "SES Library Area**. 
Listings for each tool will replace old listings as they are 
accumulated by the Release Manager. 
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2.4.2 8UILD AND VERIFICATION 



The heart of a the Scheduled Release process is the 
verification build of the tools being released. The series of 
events that occur here is briefly outlined below: 

> The Tool Submitter notifies the Release Manager of the 
readiness of the Tool for build. 

> The Release Manager (or his designate) acquires a copy 
of the Tool PL and performs the build. 

> When the build has been completed* the Submitter is 
notified* and the resulting build files are made 
available to him for verification. 

> Depending upon the outcome of the tests* the Release 
Manager Mill either accept the Tool for official 
release* or freeze it* allow the Submi tter to make 
corrective changes* and then repeat the build and 
verification sequence. 

The Pre— Release and Critical PSR Release do not involve as 
much participation on the part of the Release Manager. The 
Submitter will perform the tool build and verification from 
his own catalog* When satisfied with the results* he then 
presents the Tool to the Release Manager for "pre-release". 



2.4.3 TOOL AVAILABILITY 



Tool availability occurs in two steps. In the first step* all 
tools that are scheduled for release are required to be in 
pre-release a minimum of ten working days prior to that 
release. This point in time is referred to as the Pre-Release 
Cut-Off Day (Day 10 of the release schedule). In the second 
step* the tools are formally released. This occurs on the 
last day of the Release Period referred to as the Release Day 
(Day of the release schedule). 

Although there are many tasks that must be completed before 
the formal release of a tool* the single event which 
constitutes the actual release is the alteration of the SES 
PROCLIB file such that any procs associated with a released 
tool have been updated to reference the new version of the 
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tool* Refer to the section titled "The Scheduled Release 
Timetable** for a further summary of the other tasks that 
preceed this event* 

However* in the pre-release of a tool* the procs associated 
with that tool are updated or added to the £££ PR0CLI8 file 
and referenced fey a call in the form 

S£ S * SS S *pr ocname 
It should be noted that in any of the three release types* all 
files associated with the execution of the tool are placed in 
the SES Catalog regardless of the location of the tool's procs 
(i.e. SES PROCLIB or SSS PROCLIB). 



2.4.4 DISTRIBUTION 



The purpose of the distribution is to provide non-iocal sites 
with tools in usable form. This implies the transmission of 
only the binary files of the tools and their supporting 
procedures. No information or files needed for building the 
tool s i s sent. 

Tool distribution in conjunction with the Scheduled Release 
will be performed during the Post-Release Phase activities. 
The timetable for installation at remote sites will depend 
upon site conditions but hopefully would occur as soon as 
possible after the completion of the local release* 

The Release Manager is responsile for transmission of copies 

of the new binaries to the remote sites* Tool installation at 

these sites is the responsibility of the local SES 

representative at each site* 



2.4.5 TOOL SUPPORT 



Only the current version of any tool will be considered for 
support. Tool support is implied by the category in which the 
tool is classifieds Category If Category II* or Category III. 

LatSiaiLLX-Jl of support is provided when PSRs» RSMs* and SIEs 
written against a tool are regularly reviewed and action is 
taken to process each item according to the availability of 
resources and criticality* This is normally a tool with 
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ongoing development activity. 

£ji£,afl£.¥_ll support involves periodic review of the PSRs# 
RSMs* and SIEs written against a tool will prompt action to 
process these items based on critical ity and impact on the 
User Community. This is normally a tool with no current 
development activity. Tools in this category may be used for 
some special purpose but should be avoided in the normal build 
process if possible. 

Category III implies no support. No reported problems are 
reviewed or acted upon. This is normally a tool with no 
further development planned and should not be used in any 
phase of a build process. Tools in this category have usually 
been replaced by new tools that provide the same basic 
capabilities. 

The concept of tool support with respect to the Release 
Manager simply constitutes the management of the Tool Catalogs 
and the Tool Catalog Notebook as described in the section 
titled "Tool Catalog Management*". 
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3 * _IH£JWILfl_EHA£E-AHD-£ELEAI£fi-IIEll£ 



To begin any build of a tool* the Release Manager roust be 
notified by the Tool Submitter indicating the availability of 
the tool files for build and eventual release* This note can 
be sent to the Release Manager through SES.MAIL. Basic 
information that should be relayed is the formal name of the 
tool and the Submitter's name and phone extension. Subsequent 
items that should then be addressed ares 

> The Tool PLCs) — particularly the PL containing the 
Tool Build Document (if applicable to the tool)* and/or 
the Tool's build proems). 

> Any special instructions needed to generate the Tool 
Build Document* and/or to acquire the Tool Build Proc* 

> The user's catalog in which the Tool PL is stored* 

> To which user catalog the files resulting from the 
build should be made available for verification. 

> Who is to be notified when the files are ready for 
ver i f i cat i on. 

> Any additional comments concerning the accessing of the 
PL contents* execution of the build* or in sending a 
return notification. 



3.1 ia£.IQQL-fliilLa-OIl£lUl£HI 



Because of the complexity of a tool's composition* a Tool 
Build Document JTBD) may be necessary to outline or direct any 
potential builder of that tool in the steps required to 
properly construct that tool. The TBD is usually a TEXTCODED 
document of information and instructions usually kept in 
source form on a deck — usually named 8LDD0C — in the tool's 
main sourc PL* Its contents should clearly lay out the build 
process for the tool. Some of the basic information provided 
by the TBD (if available) is? 
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> the formal name of the tool* 

> specific file reqirements* 

> specific 'result 1 files of the build process* 

> reference to build procs that are available* 

> special external fi I e/tool /product dependencies* and 

> listings to be generated* 

The main purpose of this document is to provide the Release 
Manager with a single source that will explain all he needs to 
know about the building of the tool and the organizing of Its 
release* For less complex tools* a build proc may be the only 
"documentation" of the tool's build process* 

In either case* a tool's build proc is usually kept on a deck 
— ususally named BUILD — in the main source PL of the tool* 
When several such build procs are necessary* they are usually 
named BLDxxxx where xxxx is used to distinguish each proc in 
the build process* All build procs for . &X.&Z.X tool are 
expected to have HELP information built into it to indicate 
what tool or part of a tool is being built and* more 
importantly* what parameters are available with the proc* and 
subsequently* their default values* 



3 * 2 filUlI2_££fl££flilR£_.Sil IMLIMES 



The build procedure consists of a collection of control 
statements that will set the execution of the "build" of the 
tool into motion* Such procedures should be constructed in 
the manner of a structured program where a main procedure 
directs the control of other sub— procedur es* files* and tools 
that support the overall build* The access rabrication of any 
procedure for the build is subject to several gene 
requirements concerning its execute line* naming conventions 
for local files* and its relationship to a batch environment* 

Build procedures should use SES procs where possible and 
should be designed to run either as a batch job or 
interactively* Also* these procedures should be designed to 
accommodate use by the Tool Submitter in his daily 
operations* 

As many builds will be performed under a single catalog and 
because many files will be generated* the following naming 
convention should be used to label permanent files that will 
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be of particular concern to the Release Manager —for example* 
compiled listings of tool source* The purpose of this naming 
convention is to facilitate the task of file identification 
and dispersement with respect to the tool to which it is 
associated* The convention is as follows— 

All files created in the build process pertinent to the tasks 
of the Release Manager will be named in the form* 

xxyyyyy where xx is the two—character tool 

identifier and 

yyyyy is supplied by the 

Submitter for file name 

uniqueness within the build 
procedure* 

The names of the files that will later be transferred to the 
Tool Catalogs must be passed as parameters to the build 
procedure* File name substitution will be restricted to this 
classification of files and that the parameter list will be 
kept as limited as possible* 

If a build procedure completes normally* it should create a 
local file containing a dump of the NOS Dayfile* The named 
assigned to this file should be of the form: 

xxyyyOK 

If a build procedure terminates abnormally* it should create 
and save a file containing a dump of the NOS Dayfile and 
should be of the form? 

xxyyERR 

Local files used as scratch files during the build should use 

UNIQUEtNAME) 

to generate a random* unique file name* 

A typical build procedure should have the form of an SES 
procedure file* and can be divided into four basic parts 
--which are illustrated below* 

S£ML£-fiyiLa_££I££aURf 

1* To begin with* the build proc must have HELP 
Documentation built into it so that a user will have 
some immediate means of determining what the proc 
does and how it is initiated* Such documentation is 
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constructed as follows* 

BLDUT 

\ IF MODE * HELP THEN 
\ ROUT FA « PRIMOUT 

This procedure will direct the build 
of the PL CROSS REFERENCE UTILITY, 
The parameters are defined below* 

PARAMETERS DEFAULT DESCRIPTION 

utpl SES1054 the source PL 

utbl SES50BF 

utb2 SES50C0 

utdl SES50C1 

utd2 • • 

utd3 . • 

pr no print print all listings 

\ ROUTEND PRIMOUT 
\ STOP 
\ IFEND 

2. The next section of the proc usually establishes 
parameter definitions* default values for the 
parameters* and unique names and labels to be used 
throughout the proc* 

\ PARM KEY « »utpl f NVALS * 0..1 NAM 

\ PARM KEY ■ 'utbl' NVALS * O.M NAM 

\ PARM KEY « «utb2« NVALS * 0..1 NAM 

\ PARM KEY * «utdl» NVALS « o».l NAM 

\ PARM KEY = *utd2» NVALS * 0..1 NAM 

\ PARM KEY « »utd3« NVALS » 0..1 NAM 

\ PARM KEY « *pr* NVALS * 

\PARMEND 

\ utpl * SETVAL CSES1054»* notused* utpl) 

\ utbl » SETVAL CSES50BF'* notused, utbl) 

\ utb2 * SETVAL <«SES50CQ», notused, utb2) 

\ utdl » SETVAL (»S€S50C1«, notused* utdl) 

\ utd2 

\ utd3 



compi le * UNIQUE(NAME) 
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3* The body of the proc consists of the gencomps* 
compiles* and loads used to generate object code for 
the tool being built. In this portion of the proc 
other items such as printing of listings and maps* 
saving specified files* etc* are also addressed The 
layout and grouping of commands is left to the 
discretion of the proc writer. A proc body is 
illustrated as follows* 

SESMSG. *** BEGIN THE BUILD 

ACQUIRE{pl*£utpl£) 

ses*gencomp m*readsrc b*pl ab*( (pasccmn* ses) ) cf*£c 

ses.pascalx i»£compi i e£ l*utlllst b*Igo cc 

ses*linfcl70 pasclib f*lgo b*£utbl£ l»utllmap 

ses.rewrite i=£utbl£ o*£utbl£ CT*s M»e 

$RETURNt£compi le£> I go) 

\ IF DEFP(PR) THEN 

ses.print (utll I st •utllmap) 

\ IFEND 

$RETURN(utU lst»uti imap»£utbl£) 

SESMSG. ** FIRST BINARY COMPLETED 

ses*gencomp m«format b*pl 

ses.pascalx i*compile l*utl21st 

ses.linkl70 pasclib f«lgo b*£utb2£ I*utl2map 

ses. rewrite i*£utb2£ o*£utb2£ CT*s M*e 

$R£TURNCcompi le* I go) 

\ IF DEFP(PR) THEN 

ses.print (ut!2 I st*ut!2map) 

\ IFEND 

$RETURNCutl2ist,utl2map*£utb2£) 

SESMSG. ** SECOND BINARY COMPLETED 

ses*gencomp m*sesdirl b*p I cf*£utdl£ 

ses. rewrite i*£utdl£ o*£utdl£ CT*s M*r 

ses.gencomp i*sesdir2 b«pl cf«£utd2£ 

ses. rewrite I*£utd2£ o»£utd2£ CT*s M*r 

ses.gencomp m=sesdir3 b*pl g*£utd3£ 

ses. rewrite i*£utd3£ o«£utd3£ CT*s M*r 
$RETURN(£utdl£.£utd2£.£utd3£) 

SESMSG. ** COMPLETED DIRECTORY FILES 

Notice also how SESMSG is used throughout to continuously 
relay the flow of events to the terminal user as each set 
or portion of the command flow is executed* The use of 
this feature is particularly beneficial to the tool 
builder (i.e. the Release Manager) who is monitoring the 
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build's progress . 

4* The last part of the proc usually concludes the 
build by returning all unnecessary files from the 
working space and then constructs a copy of the 
job's dayfile. Usually* when a proc is run form a 
terminal* the dayfile is retained only as a local 
file. If an error occurs or the build proc is 
executed in batch mode* the dayfile is retained as a 
permanent file* The last portion of the proc may 
look like this? 

SESMSG. »»> BLDUT COMPLETED 

ses. dayfile find*»BEGIN THE BUILD* n*999 o*ut99ok 

EXIT. 

SESMSG. <<«< BLDUT ERRORS ENCOUNTERED 

ses. dayfile find**BEGIN THE BUILD' n=999 o»utdayf 

ses. rewrite i*utdayf o*ut99err 

$RETURN(utdayf ) 

Additional examples are included in the sub-section titled* 
"examples 1 " to further clarify build proc construction. 



3 . 3 miIAIMJa-D£-Iti£_fiiiILJ}_££Il££SS 



In general* the Release Manager will perform a build according 
to the directions presented in the build documentation from 
the Tool Submitter. 

Where the actual execution of the build may be very simple* 
the bulk of the work for the Release Manager involves several 
important preparatory and follow— up activities. These 
activities are keyed off of the Tool Build Document <TBD) 
and/or the HELP-Mode information from the Tool's build 
proc (s ) . 

To print the TBD* the Release Manager must process the 
document through the text formatter and print it — either 
locally or at a printer. With this document certain 
build-related information can be drawn out before the build is 
performed. The Release Manager should be able to identify! 

> Tool PLts) required for the build* 

> Named File and Numbered File assignments* and 

> special f i I e/pr oduct/ tool dependencies of the build 
procedure. 
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Upon completion of the build the Release Manager should be 
able to identify from this documents 

> local files resulting from the builds 

> files that are to be saved for verification* 

> files to be printed out from the build procedure* and 

> how these files are to be saved. 

The HELP information provided in the build proc can be printed 
at the terminal during build time by stating? 

ses*hel p*procname 
This information should be able to explain to the builder 
(Release Manager) all parameter options for the proc* their 
consequences (especially when the keyword name is not 
implicitly clear)* and their default values when applicable* 

Based on the information from the TBD (if available)* any 
special instructions on the Submitter's notice* and/or the 
HELP information in the Tool f s build proc* the build 
environment can be established and the build execution can 
begin* In brief* the series of tasks involved would be as 
foil ows ? 

> Identify the file requirements of the build procedure* 

{HELP information) 

> See to It that these files are present or will be 

accessible during the build execution* 

> Execute the build procedur e(s )* 

> Identify and save the resulting tool files* 

> Gather and bind the tool listings printed out* 

> Notify the Submitter of the build completion. 

When the build execution has completed* all files from the 
build are retained until tool verification indicates a 
successful build* If the verification is positive* the files 
may be purged from the build catalog* 

The build procedure execution should ajjta^s. produce a 
listing(s) — which may be optionally printed with the 
specification of a f print* keyword* As is 



convention*) Ail listings are to oe retrieved from the 
printer and separated according to tool* Listings should not 
be stored as permanent files once printed* Each set of 
listings for the tool is then bound and placed in the common 
library area at the central site* 



COMPANY PRIVATE 



CDC SOFTWARE ENGINEERING SERVICES 
SES Release Process 



3-8 
07/25/80 



3.0 THE BUILD PHASE AND RELEATED ITEMS 
3.3 INITIATION 01= THE BUILD PROCESS 



At this point* the Submitter is notified that the build is 
complete and that the tool files are available to him for 
verification. Information that is relayed to the Submitter 
usually indicates* 

> the formal name of the tool* 

> the list of tool files resulting from the build that are 

presently available in the build catalog for 
veri f i cat i on* and 

> additional comments or informative notes indicating 

deviations from the specified build procedings. 

It is expected that all files in the build catalog will have 
semi-private and read-only/execute-only permissions. No 
general write permissions will be allowed. 



3.4 JttfiiElCAUfia 



The first and foremost purpose of the Release Manager's build 
in the release process is to ascertain that the construction 
of the tool was self-contained — that is> the build process 
used only materials provided by the Tool Submitter and/or from 
standard/supported products available* 

Verification of the results of a tool's build should determine 
whether or not the tool that was produced is the same as the 
corresponding tool in pre-release. The verification is 
usually made in the following two forms* file contents 
comparision and /or tool testing. File contents verification 
involves the comparision of contents of the newly built tool 
filets) and each counter-part in the SES Catalog. the NOS 
command VERIFY is usually used to accomplish this. Tool 
testing involves the actual exercising of the tool from the 
files that were just built. 

The responsibility of file comparison and tool testing lies 
with the Submitter. The testing of the tool itself should 
have been done prior to submitting the tool for release. It 
is expected that specific tests will be developed by the 
Submitter for each tool. No particular restrictions are made 
on test composition and construction by this document or the 
release process. It is left to the Tool Submitter to 
determine the degree and the extent to which he wishes to test 
the tool since only he is accountable for tool performance 
after the official release occurs. However* testing should 
cover all pertinent files resulting from that build. 
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The Submitter will inform the Release Manager whether or not 
the tool was built properly by indicating the condition of the 
tool files resulting from the build* and will make a 
recommendation for abort* postponement* or a go-ahead of the 
tool's release. Based on this report* the Release Manager 
then decides whether to allow the release of that tool or to 
"recycle** the tool into pre-release* 



3 . 5 £*AH£L£S JQf -mLJ2_£EQ££DU££S 



The following examples are provided to exemplify the build 
procedure guidelines discussed in the previous sub-sections* 
A brief summary precedes each example to describe the 
situation being depicted and/or to point out items of 
interest. 



3.5.1 SAMPLE PROCEDURE — ACQUIRE 



This is an example of the build proc that will compile and 
link the ACQUIRE Program. Note in particular how the HELP 
Mode information is laid out. Also* how the default values 
for the parameters are set using SETVAL* the use of •UNIQUE* 
to generate unique names for scratch files (and labels)* and 
the use of SESMSG to indicate the status of the build 
throughout the proc. The body of the proc contains a mixture 
of 'SES calls 1 and KCL Commands. The use of the • R-regi sters 1 
is employed to aid the proc in determinng error conditions 
otherwise transparent to the proc. The use of this feature is 
left to the discretion of the proc writer and is not a 
necessity when constructing a build proc* 



BLDACQ 

\ IF MODE * HELP THEN 
\ ROUT FA * PRIMOUT 

This BUILD procedure compiles and links the ACQUIRE program 

PARAMETER DEFAULT ALLOWABLE VALUE(S) 

pi SES 10 80 filename (of source PL) 
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plun SESAUX username {owner of pi) 

bin SES5140 filename {for binary) 

binun current user username (owner of bin) 

list LISTING filename {for listing) 

pr no pr int keywor d 

dayf no dayfile keyword 

In addition* all of the standard SES batch job parameters are 
available including the dayfile parameter {default is to run 
the proc in LOCAL mode). If the build is successful* the 
dayfile will be left on a local file {default name is DAYFILE) 
If the build doesn f t work or the proc is run as a batch job* 
the dayfile will be saved in a permanent file in the current 
user's catalog. 



\ 


ROUTEND PRIMOUT 






\ 


STOP 










\ 


IFEND 










\ 


PARM 


KEY 


= * pi • 


NVALS « 1 


NAM 


\ 


PARM 


KEY 


a *pl un * 


NVALS * 1 


STR 


\ 


PARM 


KEY 


* 'bin' 


NVALS « 1 


NAM 


\ 


PARM 


KEY 


* 'binun' 


NVALS * 1 


STR 


\ 


PARM 


KEY 


* Mist* 


NVALS = 1 


NAM 


\ 


PARM 


KEY 


* 'pr* 


NVALS = 




\ 


INCLUDE 


•JOBPARM' L»UNIOUE{NAME) LPFN-SESLNAM UN«SESUNAM 


\ 


PARMEND 











\ INCLUDE 'J0BHDR1' L ^UNIQUE ( NAME ) LPFN'SESLNAM UN*SESUNAM 

A INCLUDE 'J0BHDR2' L*UNIQUE ( NAME ) LPFN*SESLNAM UN*$ESUNAM 

\ pi = SETVAL( f SES1080'* notused* pi) 

\ plun « S€TVAL{ 'SESAUX'* notused* plun) 

\ bin « S£TVAL( i SES51^0«, notused* bin) 

\ binun * SETVAL{USER» notused* binun) 

\ list = SETVAL{*LISTING»* notused* list) 

\ compi le » UNIQUE{NAME) 

\ Igo » UNIQUE{NAME) 

\ Igob * UNIQUE{NAM£) 

\ error » UNIQUE{ LABEL) 

\ groovy « UNIQUETLABEL ) 

\ done = UNIQUE(LABEL) 

\ solong * UNIQUE{LABEL) 

SESMSG.* BUILDING ACQUIRE 
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SES.GENCOMP* M*ACQUIRE* CF*£compi I e£* B»£pl£* UN=£piun£* .. 

NOMSG* STATUS*EF. 
$IF{EF.NE.O)$GOTO<£error£) 

SES. COMPASS* I*£coinpi le£* L*£Mst£* B*£Igo£* NOMSG 
$IF{EF.N£.0)$GGTG<£error£> 
SES.GENCOMP* M*MACQUIR* CF^coipiieS, B=£pl£* UN=£plun£, .. 

PASCCMN* NOMSG* STATUS*EF. 
$IF(EF,N£.0)$GOT0<£error£> 

SES.PASCALX* I*£compiie£* L=£list£* LO*R* 8*£lgo£* NOMSG 
$IFtEF.NE.O)$SQTO{£error£) 
SES.LINK170* F«£lgo£* B»£lgob£* PASCLIB* L»£tist£* LO* .. 

EP**ACQUIR£*$RFL*$* $SDM*$», 
$IF(EF.NE.O)$GOTO{£error£) 
SES. REWRITE* I*£lgob£* G*£bin£* UN*£binun£* .. 

FAIL£D*«£error£»* LOOPEND**£error £ f . 
$S£T(R1*0) 
$G0T0(£groovy£) 

EXIT. 

£err or £** 

SESMSG.- ERROR(S) IN BUILD OF ACQUIRE 

$SET<R1*1) 

£groovy£** 

\ IF DEFK(pr) THEN 

$IF(FILE<£H st£*.NOT.AS) ) SGGTO C £done£) 

SES. PRINT* F*£Hst£* NOSHIFT* ID**ACQUIRE* 

\ IFEND 

£done£** 

$RETURN(£compi 1e£* £ J go£* £1 gob£*£bin£) 

\ IF DEFK(dayf) THEN 

\ IF jobmode * 'LOCAL* THEN 

SES.DAYFILE* N«9999* F IND* 'BUILDING ACQUIRE 1 * G*£dayfHe£ 

EDTUdayfi I e£*0)D.S5 *. S?-1.D 

$IF<Ri.EQ.O)$GOTO(£solong£) 

\ ELSE 

$DAYFILE(£dayf i I e£ ) 

\ IFEND 

$RENAMEC£compi 1 e£»£day f H e£) 

SES. REWRITE* I«£compile£* 0«£dayflle£ 

$RETURN(£compi !e£) 

\ IFEND 

£sol ong£** 

$SET<EF«R1) 

$SET(R1«£R1£) 
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END BUILD ACQUIRE 



3.5.2 SAMPLE PROCEDURE UTLITIY LIBRARY 



BLDULIB 

\ IF MODE ■ HELP THEN 
\ ROUT FA * PRIMOUT 

This BUILD procedure compiles/assembles all of the 
components of the SES Utility Library for PASCAL-X CC programs 
and puts themn a User LIBrary ready for use with the CYBER 
Loader* 



(of source PL) 
(owner of pi) 
(for library) 
(owner of uli b) 
(for listing) 



In addition* all of the standard SES batch job parameters are 
available including the dayfiie parameter (default is to run the 
proc in LOCAL mode). If the build is successful* the dayfiie will 
be left on a local file (default name is DAYFILE). If the build 
doesn't work or the proc is run as a batch job* the dayfiie will be 
saved in a permanent file in the current user's catalog. 



PARAMETER 


DEFAULT 


ALLOWABL 


Pi 


SES109F 


f i 1 ename 


P lun 


SESAUX 


username 


ul i b 


SESULIB 


f i 1 ename 


ul i bun 


current user 


username 


list 


LISTING 


f i lename 


pr 


no pr int 


keyword 


dayf 


no dayfiie 


keyword 



\ 


RGUTEND PRIMOUT 






\ 


STOP 








\ 


IFEND 








\ 


PARM 


KEY * *pi • 


NVALS * 1 


NAM 


\ 


PARM 


KEY * *plun« 


NVALS * 1 


STR 


\ 


PARM 


KEY » »ul ib« 


NVALS * 1 


NAM 


\ 


PARM 


KEY * 'ulibun' 


NVALS » 1 


STR 


\ 


PARM 


KEY * * list* 


NVALS * 1 


NAM 


\ 


PARM 


KEY * 'pr' 


NVALS * 




\ 


PARM 


KEY « 'dayf 1 


NVALS * 




\ 


INCLUDE 


•JOBPARM* L*UNIQUE(NAM£) LPFN 


■SESL.NAN UN*SESUNA 


\ 


PAR MEND 
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\ INCLUDE 'J0BHDR1* L*UNIOUE< NAME ) LPFN*S£SLNAM UN*S£SUNAM 
\ INCLUDE 'JQBHDR2 1 L«UNIQUEC NAME) LPFN*SESLNAM UN»SESUNAM 

\ pi « SETVAL<*SESI09F», notused* pi) 

\ plun * SETVALC'SESAUX'* notused* piun) 

V ylib * SETVALt 'SESULIB'* notused* ulib) 
\ ulibun * SETVALCUSER* notused* ulibun) 

\ list = SETVAL(*LISTING«* notused* list) 

\ cowpi 1e * UNIQUE(NAME) 

\ Igo * UNIQUE<NAME) 

\ tempi ib = UNIQUE(NAME) 

\ error « UNIQUE< LABEL) 

\ groovy « UNIQUEtLABEL) 

V done * UNIQUEtLABEL) 

V solong = UNIQUE! LABEL) 

SESMSG.* BUILDING SES UTILITY LIBRARY 

SES.GENCOMP* MM BLNKSTR . .CVASC64* ZBIICLO. . ZBII WEO* ZDI ICLO. .ZDIISTF* .. 

ZIOICLO..ZIOIQRY* ZLGICLO. . ZLGIWEO* ZPRIOPN..ZPRIOUT )* .. 

CF»£compi ie£* B*£pf£* UN*£plun£* •• 

NOMSG* STATUS«EF. 
$IFtEF.NE.O)$GOTOt£error£) 

SES.PRINTID* ID* , SESULIB/PXIQ/COMPASS//)DATE*» 0*£i ist£ 
SES. COMPASS* I*£compile£* L»£list£» B«£lgo£* NOMSG 
$IFCEF.NE.O)$GOTO(£error£) 
SES.GENCOMP* MMZCLIIAP)* .. 

CF*£compi le£* B«£pl£* UN*£plun£* •• 

NOMSG* STATUS-EF. 
$IF(EF.NE.O)$GOTOt£error£) 

SES.PRINTID* ID»»SESULIB/SCL/COMPASS//)DATE», 0-£tlst£ 
SES. COMPASS* I*£compile£* L»£list£* 8»£lgo£* NOMSG 
$IF(EF.NE.O)$GOTGt£error£) 
SES.GENCOMP* M«{ ZCLMANT. .ZCLMXFT* ZGSMEND. . ZOSMSSA* ZPMMDAT. .ZPMMTIM )* .. 

CF*£compi le£» B«£pl£* UN»£plun£* .. 

NOMSG* STATUS*£F. 
$IFt€F.NE.O)$GOTOt£error£) 

SES.PRINTID* ID«*SESULIB/SCL/PASCAL~X//)DAT£** 0«£list£ 
SES.PASCALX* CC* I»£compi I e£* L*£list£* B«£lgo£* NOMSG 
$IF(EF.NE.O)$GGTOt£error£) 
SES.GENCOMP* M*l ZN7ICI0. . ZN7IWNB* ZUTI AST. .ZUTISFN) * .. 

CF«£compile£* B*£pl£* UN»£plun£* AB«(tOPL* LIBRARY))* .. 

NOMSG* STATUS*EF. 
$IFt€F.NE.O)$GOTOt£error£) 

SES.PRINTID* ID**SESULIB/MISC./COMPASS//)DATE«* 0*£Hst£ 
SES. COMPASS* I*£compiie£* L*£ltst£* 8»£lgo£* NOMSG 
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$IF(EF.NE.0)$G0TG<£error£} 

SES.GENCOHP* M* i ZN7MAQR* • ZN7MRDR* ZUTMAQR . , ZUTMW20 ) » .. 

CF*£cojnpi le£> B«£pl£> UN*£plun£* • • 

NOMSG* STATUS*EF. 
$IF{EF.N£.Q}$GaTOC£errof£) 

SES.PRINTID, ID=*SESULI8/MISC./PASCAL-X//)DAT£«, = £l ist£ 
S£S»PASCALX> CC> I*£compiIe£* L*£list£* B»£igo£# NOMSG 
$IF?EF.NE.0)$G0T0(£error£) 

$LIBG£NCF*£I go£, P*£ tempi i b£»N*SESULIB»NX*l ) 
SES. REWRITE, I*£templib£> 0*£ulib£> UN»£ulibun£, .. 

FAILED« , £errof£«» L00PEND»»£error£» . 
$SET(R1«0) 
$G0T0<£groovy£) 

EXIT. 

£err or£>* 

SESMSG.- ERROR(S) IN BUILD OF SES UTILITY LIBRARY 

$SET<R1*1) 

£groovy£>* 

\ IF DEFKCpr) THEN 

$IF(FILEC£I ist£*.N0T.AS))$G0T0(£done£) 

SES. PRINTS F«£iist£, NOSHIFT, ID*»SES/UTIL ITY/LIBR ARY/ / ) DATE f 

\ I FEND 

£done£>* 

$RETURN(£compi Ie£* £1 go£> £templib£> £uH b£ ) 

\ IF DEFK(dayf) THEN 

\ IF jobmode * 'LOCAL* THEN 

SES.DAYFILEj N*9999, F IND- ' BUILD ING SES UTIL*> 0»£dayfi!e£ 

EDT(£dayfne£,0)D.S;*.S5~l.D 

$IF(Rl.EQ.0)$G0T0(£sol ong£) 

\ ELSE 

$DAYFILEC£dayfi 1e£) 

\ IFEND 

$RENAME(£compi le£=£dayf i le£) 

SES. REWRITE* I*£compi!e£> 0»£dayfile£ 

$RETURN<£coropl le£) 

\ IFEND 

£solong£#* 

$SET<EF»Ri) 

$S£T(R1«£R1£> 

* END BUILD SES UTILITY LIBRARY 
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3.5.3 SAMPLE PROCEDURE VE LINKER 



8LDLD 

\ IF MODE * HELP THEN 
\ ROUT FA * PRIMOUT 

This procedure compiles the modules for the VE Linker. 
It's parameters are shown below* 

PARAMETER DEFAULT DEFINITION 

idpl SES106C source PL 

Idol SES5118 object library containing relocatables 

Idov SES5117 relocatable containing the overlay bin 

pr no print when specified* will print all listing 



\ ROUTEND PRIMOUT 
\ STOP 
\ IFEND 

\ PARM KEY * » I dpi * NVALS * 0..1 NAM 

\ PARM KEY * MdoM NVALS * 0..1 NAM 

\ PARM KEY « »ldov» NVALS * 0..1 NAM 

V PARM KEY « *pr* NVALS » NAM 

\ PARM KEY * «dayf» NVALS » NAM 

\ PARMEND 

\ Idpl * SETVAL <»SES106C«» notused, Idpl) 
\ Idol * SETVAL <*SES5118«# notused* idol) 
\ Idov ■ SETVAL ( , ses5117 , » notused* Idov) 

SETTLW777. 
RETURN»LISTING,LGO, 
RETURN, LDERROR. 
RFL>20000. 

** COMPILE THE LINKER AND ITS OVERLAY SCHEME 

SES.GENCOMP ZLDM000 B*£ldpl& AB* C (SESPLXX, SES ) ) 

SES.ISWL LARGE LO*R L-LINKLST 

SES.GENCOMP ZLDM100 B*£ldp»£ ABM< SESPLXX, SES ) ) 

SES.ISWL LO=R L*LINKLST 

SES.GENCOMP ZLDM200 B*£fdpi£ AB* U SESPLXX, SES ) ) 

SES.ISWL LO»R L«LINKLST 

SES.GENCOMP ZLDM300 B»£ldpl& AB« ( ( SESPLXXjSES ) ) 

SES.ISWL LO=R L*LINKLST 
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SES.GENCOMP ZLDMSSC B=£ldpt£ AB* U SESPLXX, SES )) 
SES.ISWL LO*R L*LINKLST 

\ IF DEFPCpr) THEN 
SES. PRINT LINKLST 
\ IFEND 

SES.REPULIB G*LGO B*£»dol£ NX 

RETURN, LGO, LINKLST. 

SES.GENCOMP ZLDILNK B»£ldpi£ AB* ( ( SESPLXX, SES ) ) 

SES.COMPASS L*LINKLST 

SES.GENCOMP ZLDMDUM B*£ldp»£ AB* ( i SESPLXX, SES) ) 

SES.ISWL LO«R L*LINKLST 

SES.GENCOMP ZLDIQVL B*£1dp1£ AS* C f SESPLXX, SES ) ) 

SES. COMPASS L*LINKLST 

SES. REWRITE I = LGO O*£idov£ 

\ IF DEFP(pr) THEN 

SES. PRINT LINKLST 

\ IFEND 

* BLDLD COMPLETED 



EXIT. 

PACK, LINKLST. 

SES. REWRITE I»LINKLST 0*LDLIST 

SES.DAYFILE FIND** SETTL, 7777. • N*999 0*LDERROR. 

SES. REWRITE I*LDERROR 

* BLDLD ERRORS ENCOUNTERED 
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4.0 _HIS££LUIi£IlUS-J!lflI£S 



4 . 1 I2J2i_m££I!l_nS£AMIJ:AIIQM 



A tool roust be completely contained on a minimum number of PLs 
i hopefully one). The composition of "this PL" must consist of 
** a I I •» the tool source code necessary for tool gener ation* 
"all** the build procedures needed to perform the build* the 
source necessary to produce the documents required* and test 
cases for tool verification. 



4*2 IflflL_ME£Mfl£li£IES 



The dependence of one tool on others practically always turns 
out to be much more intricate and complicated than anyone at 
first supposes. However* it is possible to confine the 
dependencies to specific areas in the build procedures and 
therefore* make it much easier to insure that the proper 
versions of other required tools are used, A conscious effort 
should be made on the part of the build procedure writer to 
reduce the number of inter-tool dependencies to as few as 
possible* 



4.3 £AIALM.fl£££Hft£ia£IJES 



The problem of moving a tool from one catalog to another or of 
extracting required tools or files from the proper catalogs 
has long been a difficulty that has forced past release 
managers to constantly modify build procedures M on the fly w « 
It is therefore expected that in all release procedures the 
need to acquire files — other than files that are submitted as 
part of the build process — will only be from the Tool 
Catalogs* In addition* such files should be supported tools 
or products* 
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4,4 £S£._£0EE££IIim£ 



PSRs written against the product will be routed to the Tool 
Submitter via the PSR Coordinator* It will be up to the 
Submitter to inform the Release Manager of the situation* 
Arrangements for non-critical corrections should be made to 
coincide with a Scheduled Release* 

Critical corrections are transmitted to the general SES User 
Community according to the following series of steps? 

1 The creation of a substitute tool binary by the 

Submitter* 

2 Give the Release Manager access to the new binary file* 

3 The Release Manager will place the corrected version of 

tool in the SES Catalog* 

4 The Tool Proc in SES PR0CLI8 will be adjusted to call the 

new version of the Tool. 

5 The Tool Submitter will provide notification of this new 

version of the tool to the SES User Community through 
SES*INFQ. 

During the next Scheduled Release* the Submitter is expected 
to follow up with Scheduled Release procedures in order to 
properly document the change* 
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5 * _IM£_S£tif m£fi_R£L£A£E-IIfi£IMLf 



It usually requires fifteen (15) working days to complete the 
Scheduled Release activities* Projects must submit materials 
and complete certain tasks by the days indicated in the 
schedule below — or sooner* if desired* 

Although the exact schedule may vary within any given Release 
Period* the following layout indicates the general occurrence 
of events with respect to specific points in the release 
schedule activities* Day 10 marks the first working day of 
the Release Period* Day -5 is the last working day of that 
period* 



before Day 10 

The Submitter should have all of the essential coding 
complete and should be confident that the tool will 
execute properly. 

The Submitter should have isolated and documented all 
the dependencies his tool has on other tools that are 
being co— released* 

All changes for the SES User's Handbook documentation 
should be turned into the Release Manager at this 

time* 

The Submitter will supply the Release Manager with a 
brief description of the new tool or changeCs) from the 
old tool for inclusion in the Tool Availability 

Bui 1 e ti n* 

The Submitter should have completed the writing of a 
tool build document (if necessary)* and the 
construction of build procedures. 

The Submitter will inform the Release Manager of the 
availability of the tools for pre-release. 
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Day 10 



Ail tools that will be released will be set-up in the 
pre-r el ease. 



before Day 



Day 



The Release Manager will make the TAB available to the 
SES User Community* 

The Release Manager will make the newXupdated ERS 
materials available to the SES User Community via 
T00LD0C. 

The Release Manager will have constructed and reviewed 

the SES User Handbook* presented it to DCS for 

di str i but ion* and made it available to the SES User 
Community via TQQLDOC. 

The Release Manager will begin verification builds of 
the tools and will notify the Submitter when the 
completed tool is ready to be verified. (This will be 
an on-going activity up until Day -5.) 



The Release Manager will give public access to the new 
tools. 



before Day -5 



The Submitter will have completed the verification that 
his tool was built correctly* 

The Release Manager will complete the verification 
builds on all tools of the release. 

The Release Manager will have created a set of tapes 
containing SES Tools and have sent them to the 
non-1 ocal s i tes. 



It is important to note that in following any release 
schedule* it is expected that all designated tool materials 
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will be available by the days specified In the schedule* 
However* it is acceptable to submit tool materials sooner than 
the schedule shows. 
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6.0 _im_£MALI2£._MM£Eil£MI 



6.1 laiEflDUCIIfit! 



The "Tool Catalog** is a collection of SES tools and files and 
actually consists of three catalogs* the principle catalog 
which is referred to as the SES Catalog* the SESAUX Catalog 
also referred to as the Auxiliary Catalog* and the SSS Catalog 
which is the "pre-release** catalog* 

The reason for the multiple catalogs is to provide the Release 
Manager with a means to control the archiving of tool files 
periodically done by COMSOURCE. The SES Catalog contains only 
those files necessary to execute the current and released 
versions of the tools. Since it is inconvenient to have files 
of this nature archived* the RETAIN proc is periodically 
executed to retain those files in the catalog. The SESAUX 
Catalog contains the remaining SES tool files — such as PLs 
and backup files or those files from previous SES releases. 
The SSS Catalog* by practice* holds only the PROCLIB 
containing the procedures for executing the Pre-Release 
versions of tools. 

When newer versions of existng tools are released* tool files 
from the previous release and currently residing in the SES 
Catalog are transferred to the Auxiliary Catalog. The tool 
files now in the Auxiliary Catalog then become subject to the 
COMSOURCE archiving policies and thus* lends to the support of 
the release process objective which is to provide for 
reproducibility of any desired version of a tool. 



6.2 £AIAJ.flfi-CflMI£MIS 

The contents of the SES Catalog and the Auxiliary Catalog are 
subdivided into two basic types — source files and binary 
files. 
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Files in the Tool Catalogs are assigned unique names by the 
Release Manager to avoid naming problems and to provide a 
general identification of the file contents. The general form 
of the name is* 

SESnnnn where nnnn represents the numbered 
portion of the name. 

The unique names for submitted files allows the Submitter to 
properly identify and verify new files prior to release* and 
also ensures that w old»* versions of tools can be retrieved 
from Archive. 

Some files in the SES Catalog will have more meaningful names 
{e.g. PASCLIB) because they might be accessed explicitly by 
such names rather than through an SES Procs. The contents of 
these files are updated on Release Day. However* any 
specially named files are still assigned unique names for 
backup and retrieval capabilities of old versions. 



6.3 fiA5I£_R£S£0HSIftlLIII£$ 



Management of the Tool Catalogs as handled by the Release 
Manager entails the following responsibilities* 

> to assure that the latest version and/or level of any SES 

tool file is always available* 

> to make older versions and levels of any SES tool file 

available upon request— this usually implies the 
un-archiving of files* 

> to maintain an updated list of files in both catalogs* 

> to remove unnecessary files from either catalog* 

> to assure that proper access permission is established on 

all the files* 

> to assign numbered file backups to all Named Files* 

> to replace files that have **gone bad*** and 

> to replace critical PSR corrected files. 



6 . 4 iaBL-£AIlU£J!lflI£iQflli-llAliAfi3y!£HI 



The Tool Catalog Notebook is a textcoded record of all the 
numbered file assignments made to the Tool Catalogs. 
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6.0 TOOL CATALOG MANAGEMENT 

6*4 TOOL CATALOG NOTEBOOK MANAGEMENT 
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A 1.0 _A££jEMILLX-A— IEBfllMflLMI 



Tool 

A tool is a facility to aid in producing products with 
minimal expenditure of time* labor* and materials* 

Product 

A collection of files made available for company customer 
use <with support). 

Software Too I s 

Software tools are defined as the software (or firmware) 
programs that aid in the development of software. 

Software Engineering 

A branch of engineering in the computer industry whose 
function is to plan the processes of manufacture* 
development* and integration of software with minimal 
expenditure of time* labor* and materials* 

Software Engineering Services or 
SES 

A group of people providing software development tools for 
Advanced Systems Development* 

SES Tool 

A software tool developed by* supported by* and/or made 
available through SES* 

Tool Identifier 

A two-character identifier uniquely assigned to each SES 
tool for identification of files and for tracking PSR 
information* 
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Tool PL 

A program library containing the tool source code* build 
procedure* documentation* and test cases* 

Tool Build Document or 
TBD 

A deck on in the Tool PL named f *BLDD0C M that usually 
consists of a single page of text identifying the tool and 
describing the requirements necessary to build it* 

Re I ease 

The process by which SES Tools are made **ava i lab I e" for 
company internal use (with support)* 

Release Period 

The time within which specific SES Projects are scheduled 
for completion and their products are made available to the 
general SES User Community* The Release Period consists of 
two parts: a Pre-Release Phase and a Post-Release Phase* 

Pre-Release Phase 

The time in which tools are made available before their 
scheduled release for other projects co-releasing tools* 

Post— Release Phase 

The time in which the Release Manager completes build 
activities and sends the released tools to the remote 
si tes* 

Pre-Release Cut— Off Day 

The point in the Pre— Release Phase by which aJJ. tools 
scheduled to be released are placed in pre-release status* 
Also* referred to as "Day 10 M * 

Release Day 

The point in the release process at which new/revised tools 
are made available to the general SES User Community* Also* 
referred to as "Day 0"* 
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Aborted Release 

A situation occurring before the official release in which 
submitted files have to be modified after tool verification 
discovers a problem with the tool. 

SES Release Manager 

The person who acts as the release co-ordinator and is In 
charge of maintaining the presence of SES Tools in the SES 
Catalog, 

Subm i tter 

The person responsible for the release and maintenance of an 
SES tool* 

Tool Bui Id Procedure 

A sequence of control statements and/or control language 
statements that directs the file manipulations necessary to 
construct (build) a tool. 

Tool Catalog (s) 

The collective term used when referring to all of the S£S 
Tool catalogs: SES> SSS> SESAUX. 

SES Catalog 

The collection of permanent files consisting of SES Tool 
binaries necessary to execute a tool. The "no-archive" bit 
is set for this catalog* 

SESAUX Catalog 

The collection of permanent files consisting of backup files 
and source Pis for SES Tools. This catalog is set to allow 
for archiving. 

SSS Catalog 

Holds only the PROCLIB file which contains the procedures 
necessary to execute Interim and PSR type versions of 
tools* This catalog is set to allow for archiving. 
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SES Users 

A group of people who use SES Tools* 

Tool Aval f ability Bulletin or 
TAB 

A bulletin identifying the new/changed tools of a release 
and briefly describes the new tooMs operation and function 
or the user level changes made to an old tool» 

Documentation Control System or 
DCS 

The agency used by SES for tool documentation distribution 
wi thin CDC* 



COMPANY PRIVATE 



Bl-1 
CDC SOFTWARE ENGINEERING SERVICES 

07/25/80 
SES Release Process 

B1.0 APPENDIX B BIBLIOGRAPHY 



B1.0 _A£££MiJIX-fi— fiiaUQfi&A£ai 
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